How about adding the grid-gap property with class name as grid-gap-{key}, this way we can set both the column and row gap using a single class.

Nice one!
But I see inconsistency in using col(s) and grid-column-gap
Wasn't it supposed to be grid-col-gap?

I think you should drop 'grid-' from grid-column-gap and grid-row-gap as the spec now defines these as simply row-gap and column-gap https://developer.mozilla.org/en-US/docs/Web/CSS/gap

Also because these properties will apply to the subgrid and flex display types soon too

There is no grid- prefix on the gap utilities already 👍🏻

Ahh my bad, mistook the heading of the related sections. Looks like a really solid and flexible implemention

@adarsh4d Good catch on the gap-* utilities, I somehow totally missed that. I've added those and removed the default col-gap and row-gap values to keep the file size from ballooning completely unnecessarily (but the utilities are still there if you wanted to add values yourself).

One thing I'm wondering, in the latest version of the spec these properties are just gap, col-gap, and row-gap respectively, but you still need the grid- prefix in Safari and non-Chromium Edge. Unfortunately autoprefixer doesn't handle this case for some reason, so I don't feel super comfortable shipping them without the prefixes but I also don't really want to add them manually.

Should we just use the old names since they will be supported forever anyways? Should we manually prefix? Should I annoy @ai to reconsider prefixing them in autoprefixer? 👀

@adamwathan Remember the bug in Flexbox and CSS Grid with overflow and fr units.

Solution: Use the hack minmax(0, 1fr);

@Dan503 do you think that it is safe to use Autoprefixer Grid in this case?

@MrJmpl3 I'm not familiar, any chance you could share something for me to learn more about it?

Edit: Looks like it's explained pretty well here:

https://css-tricks.com/preventing-a-grid-blowout/

I'll update to use minmax(0, 1fr) instead of just 1fr 👍

Pushed a change to rename the gap related core plugins, and include both the old and new property names for each utility to maintain backward compatibility with older browsers manually. I really feel like this is a great candidate for autoprefixer though, because you can detect whether or not this actually needs to happen based on the user's browserslist config.

gap auto-prefixing

@ai I think Autoprefixer should support gap to grid-gap conversions. If you think about it, grid-gap is just a prefixed version of gap now that has become outdated. The only difference between this and a more typical prefix is that it doesn't have a dash at the start and isn't specific to one browser.

grid-column-end

In the documentation, you should add a note that IE does not support grid-column-end in any form even with Autoprefixer.

grid-template-rows

gridTemplateRows: {
  '1': 'repeat(1, auto)',
  '2': 'repeat(2, auto)',
  '3': 'repeat(3, auto)',
  '4': 'repeat(4, auto)',
  '5': 'repeat(5, auto)',
  '6': 'repeat(6, auto)',
  '7': 'repeat(7, auto)',
  '8': 'repeat(8, auto)',
  '9': 'repeat(9, auto)',
  '10': 'repeat(10, auto)',
  '11': 'repeat(11, auto)',
  '12': 'repeat(12, auto)',
},

Update

... actually... IE does have implicit rows that are auto sized by default. Modern browsers also have implicit rows that are auto by default. There is no need to explicitly tell the browser how many rows to use if all the row heights are auto in height. All this would do is add needless bloat to the CSS.

grid-row / grid-row-start / grid-row-end

I think the same default values that you provide for grid-column should also be applied to grid-row as well.

Imagine a scenario where all you want to do is place a grid cell on the second row of the grid. That is a scenario that you would expect Tailwind to support. If you provide no default values at all though then that isn't going to be possible without extra configuration settings.

This provides a reasonable amount of rows for smaller row counts and you can create a square that is 12 columns by 12 rows without having to add any custom settings.

Higher row counts will require user configuration.

You might also want to add /* autoprefixer: off */ control comments to the grid-[column/row]-end classes to prevent Autoprefixer from displaying warnings about not supporting grid-[column/row]-end.

If not, people will be flooded with the following warning message:

autoprefixer: C:\xxx\src\_styles\main.css:644:3: Can not prefix grid-column-end (grid-column-start is not found)

@adamwathan Here explain the bug, https://css-tricks.com/preventing-a-grid-blowout/

Edit: I see the edit.

@Dan503 Thanks a ton for your input, really appreciate it!

I think the same default values that you provide for grid-column should also be applied to grid-row as well.

My instinct is definitely to agree with you but every time I try to think of real-world practical situations where this would be useful I struggle to come up with any. To me it feels like being able to control which row an element appears on is not useful unless there are a fixed number of rows 🤔

Can you think of any good examples of layouts/designs that we can use as a reference for helping determine what default values would actually be helpful?

To me it feels like being able to control which row an element appears on is not useful unless there are a fixed number of rows 🤔

It is useful for creating vertical white space in the design.

Try looking through some of the crazy things Jen Simmons has done as demos.

https://labs.jensimmons.com/

IE does have implicit rows that are auto sized by default. Modern browsers also have implicit rows that are auto by default.

When I said this, I was not referring to autoplacement. You can place things on the implicit grid explicitly. This code pen shows what I mean. That pen also works in IE if you view it in Debug mode.

https://codepen.io/daniel-tonon/pen/YvjLaa

There is no need to explicitly tell the browser how many rows to use if all the row heights are auto in height.

What I meant by that is that doing something like grid-template-rows: repeat(12, auto); is pointless because the implicit grid essentially gives you infinite auto sized rows by default for free on every grid.

The one use case where this logic breaks is if you want to use grid-row-end: -1. -1 counts from the end of the explicit grid and no explicit grid has been defined. That isn't a common enough use case though to be worth bloating the CSS with things like grid-template-rows: repeat(12, auto);

I asked Andrey if he could add gap to grid-gap conversions to Autoprefixer but he refused since it isn't an actual vendor prefix.

He said that he would add a warning to use postcss-preset-env though. The warning would appear if gap is detected without grid-gap and the browserslist config suggests that grid-gap is needed.

postcss/autoprefixer#1274

Would it be possible to import the grid component of Tailwind into projects without importing all of Tailwind?

I can see myself using these grid utilities but I don't want to go all in on using Tailwind to style everything on my sites.

@Dan503 If you use PurgeCSS, any Tailwind classes you don't use will be gone anyway.

Would it be possible to import the grid component of Tailwind into projects without importing all of Tailwind?

Yep this is totally possible, you can use the corePlugins config option to specify which Tailwind utilities you actually want.

To just get grid utilities you'd do this:

// tailwind.config.js
module.exports = {
  corePlugins: [
    'display', // to get the `.grid` utility, but you'll also get `.block`, `.inline`, etc. so consider if you actually want that
    'gridTemplateColumns',
    'gridTemplateRows',
    'gap',
    'columnGap',
    'rowGap',
    'gridColumn',
    'gridColumnStart',
    'gridColumnEnd',
    'gridRow',
    'gridRowStart',
    'gridRowEnd',
}

Gaps are possible through Autoprefixer...though it needs to all be in the same rule so you might have a point there. I disagree in general about CSS Grid being more trouble than it is worth though.

All I'm asking for are a few Autoprefixer control comments to prevent the warnings from appearing, then developers can decide for themselves if they think it is worth the trouble or not.

If I'm not wrong the grid implementation in tailwind is aiming to bring basic columns and rows. If there's no autoplacment in IE and you need a class for every cell in order to place it in the right slot, that means more code than just using flexbox.

I get it, you only need a comment in there. But maybe other devs don't want such a verbose output. I could be wrong.

can you please just add /* autoprefixer: off */ to the classes that cause Autoprefixer warnings?

These warnings will only appear with the grid: "autoplace" option enabled right? I'll explore it, it's surprisingly more complicated than it sounds to add the comments, because postcss-js (the library we use for creating the CSS) has no way of creating comment nodes.

I still think you should just not use CSS Grid if you have to support legacy browsers personally. I've literally never actually needed CSS Grid for any project I've ever worked on 👀

Somewhat related, still surprised prefixing column-gap as grid-column-gap is outside of Autoprefixer's scope but doing all this complex rule creation to try and translate grid rules for IE11 is in scope 🤔

I love grid, you can build columns in a breeze with much less code. You can even (almost) build responsive columns without mediaqueries. The problem is grid-template-columns —when using minmax() function. If the min value is greater than the viewport width you'll get an horizontal overflow.

When min(), max() and clamp() get wider support we'll be able to create reponsive grid without mediaqueries. That's when people will really get onboard.

/* Now */
.mygrid {
  display: grid;
  gap: 1.5rem;
  /* Horizontal overflow in small devices */
  grid-template-column: repeat(auto-fit, minmax(400px, 1fr));
}

/* When min, max and clamp get wider support */
.mygrid {
  display: grid;
  gap: 1.5rem;
  /* No more overflow issues */
  grid-template-columns: repeat(auto-fit, minmax(min(400px, 100%), 1fr));
}

@adamwathan There are some cases when using Grid makes more sense than Flexbox. Supporting IE11 in those cases is less painful. One of those scenarios could be when building masthead menus (logo on one side, menu in the other).

Wes Boss has a great free course about CSS Grid https://cssgrid.io/. In "Flexbox Vs CSS Grid" video he explains good cases for using CSS Grid over Flexbox. Worth checking out.

I put together a bit of a demo to demonstrate how people might make use of rows in tailwind:

https://codepen.io/daniel-tonon/pen/YzPEOWN

It is IE11 compatible. You can view the IE version by viewing in Debug mode and pasting the debug mode url into IE11.

I didn't make it responsive since the goal was just to show the use case.

The row declarations for the main outer layout aren't necessary in modern browsers but they are needed for IE compatibility.

The rows for the listing are necessary in modern browsers since the image comes after the title in the HTML for accessibility.

How about adding negative start\end columns by default?

module.exports = {
  theme: {
    numbers: {
      '1': '1',
      '2': '2',
      '3': '3',
      // ...
    },
    extend: {
      gridColumnEnd: (theme, { negative }) => negative(theme('numbers')),
      gridColumnStart: (theme, { negative }) => negative(theme('numbers')),
    },
  },
}

imho it's really useful and rarely mentioned.

.-col-end-1 will make cell span to the end of row.
.-col-start-2.-col-end-1 and cell will be always last no matter how many columns grid have.

Just to chime in on grid rows and why I believe that the gridRow, gridRowStart and gridRowEnd should be included in the default.

So I am currently building the following design.

This is to a degree a standard desktop layout of a modern design, where elements sit in columns that overlap rows and sometimes will overlap columns. Looking at several of my recent designs and other designs across the web, non-symmetrical layouts and overlapping design elements are quite trendy and becoming quite common (IMO and from my observation).

So taking the above design, I started to craft this together using the current 1.2.0-canary.5 build (at the time of writing). It become apparent quite early on that I was going to need css-grid rows.
So as a starting point I included the following config:

    gridRow: theme => theme('gridColumn'),
    gridRowStart: theme => theme('gridColumnStart'),
    gridRowEnd: theme => theme('gridColumnEnd'),

What this allowed me to do was to set the rows for the main areas:

• breadcrumbs
• the tile image
• content (title and accordion content)
• decorative image

By doing this I was then able to get the breadcrumbs and content sitting next to each other without a huge gap as without setting any rows, the rows would automatically be the height of the tile. As this was the first row.

This screenshot illustrates best:

By adding the rows into the config, I could then create the following:

Here is the final html that was used for the above:

  <main role="main" class="container px-6 pt-12 // grid gap-6 grid-cols-1 lg:grid-cols-8">
    
    
    <div class="relative lg:col-span-2 lg:row-span-2 max-w-xs">
      {% include 'pages/staff-handbook/_partials/tile.twig' %}
    </div>
    
    
    <div class="lg:col-span-5 lg:col-start-5 lg:row-start-1 lg:row-span-1">
      {% include 'pages/staff-handbook/_partials/breadcrumbs.twig' with { homeTitle: 'Staff Handbook'} %}
    </div>
    
    <article class="lg:col-span-5 lg:col-start-5 lg:row-start-2 lg:row-span-3">
      
      <h1 class="font-sans text-24 text-brand-grue-500 font-bold">{{ entry.title }}</h1>
      
      
      <div class="max-w-xl">
        {% for entry in entries %}
          <accordion title="{{ entry.title }}" {{ loop.first ? ':open="true"' }} class="border-b border-gray-200 pb-2 mb-8">
            <template #open>
            <span class="w-8 h-8 p-1 text-white bg-brand-grue-500 inline-flex mr-2">
              {{ svg('@webroot/assets/svg/Interface/plus-ui.svg', class='fill-current flex-shrink-0') }}
            </span>
            </template>
            
            <template #close>
            <span class="w-8 h-8 p-1 text-white bg-green-500 inline-flex mr-2">
              {{ svg('@webroot/assets/svg/Interface/minus-ui.svg', class='fill-current flex-shrink-0') }}
            </span>
            </template>
            <template #content>
              {% include 'pages/staff-handbook/_partials/matrix.twig' %}
            </template>
          </accordion>
        {% endfor %}
      
      </div>
    
    </article>
    
    <figure class="lg:col-span-2 lg:col-start-3 lg:row-start-3 px-8"
    >
      {% include
        '_includes/_components/image.twig' with {
        image:entry.tileImage.one,
        transform:'base',
        alt: entry.title,
        sizes:'auto',
        lazyLoad: 0,
        classes:'',
      } %}
    
    </figure>
  </main>

I think when it comes to building layouts, including the CSS grid rows is essential. It gives much more flexibility out the box, to be able to position elements and also finer control to move the order of these items around across different devices/breakpoints.

I think without rows, you are pretty limited to building just simply grids that are equal. So things like card and tile (grid) layouts, like this:

Based on the above @adamwathan, if you agree to implement then it also might be worth changing the naming for the gridColumn, gridColumnStart and gridColumnEnd if they were used across both columns and rows, as I did in my config.
Having said this, I do suspect the requirement for the number of rows would be less (perhaps half) of that of the columns, but as we are likely talking a few bytes, it is perhaps sensible as a default for both to be same.

@adamwathan would you also consider including '24': 'repeat(24, 1fr)', as a default for the Grid Columns? I have often designed to a 24 column grid as I fine it gives finer control over spacing as columns are half the size.

https://www.deeson.co.uk/blog/why-i-often-use-24-column-grid

I feel like supporting 24 columns by default adds a bit too much bloat 😕

In my opinion there are not a lot of people who use it on regular basis. You can always extended the column to your needs, or create a plugin and use it in all the projects.

did i miss a note on justify\align\content ?

.content-stretch { align-content: stretch } is possible and useful on grid.
I am also missing ~ self-justify-center: { justify-self: center } and i am not sure hot this should be called, but already using it...

@gcoda Seems this might be the case...

@adamwathan said in #868 (comment)

this is something that would come along with CSS Grid support

@adamwathan did you have any further thoughts on rows and also negative grid lines?

@gcoda I submitted an issue about fixing grid support for the existing align/justify properties: #1354

getting flooded with dozens and dozens of warnings

 warning  in ./src/assets/css/tailwind.css

Module Warning (from ./node_modules/postcss-loader/src/index.js):
Warning

(3:1) grid-gap only works if grid-template(-areas) is being used

anyone know how I can stop those?

@vesper8 I think this is coming from Autoprefixer.
Do you have anything like grid: "autoplace" in your .browserslistsrc file or autoprefixer settings?

@terryupton ahh.. I see.. the only mention of autoprefixer anywhere is here in my postcss.config.js

/* eslint-disable global-require */

const tailwindcss = require('tailwindcss');
const autoprefixer = require('autoprefixer');

module.exports = {
  plugins: [
    tailwindcss('./tailwind.config.js'),
    autoprefixer({
      add: true,
      grid: true,
    }),
  ],
};

I had a freelancer designer add this there.. unsure if it's necessary.. I should set grid to false you think?

@vesper8 I think setting it to false will remove those warnings, whether that is a bug I am not sure?
But also if you are using grid and v1.2 of Tailwind, would you need to support IE11 anyway?

@vesper8 yes, you will need to set grid to false. If you are writing any custom CSS and you want to support IE11, you can add a control comment inside the rule like this:

.custom-grid-container {
  /* autoprefixer grid: autoplace */
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: repeat(5, auto);
}

The tailwind grid implementation doesn't support IE11.

It could support it if it was able to output control comments to disable certain rules but apparently the infrastructure to support that hasn't been built.

There is a way to disable all this?

Im using

corePlugins: {
        gap: false,
        columnGap: false,
        rowGap: false,
        gridColumn: false,
        gridColumnEnd: false,
        gridColumnStart: false,
        gridRow: false,
        gridRowEnd: false,
        gridRowStart: false,
        gridTemplateColumns: false,
        gridTemplateRows: false,
    },

But there is still grid classes in resulting .css

Never mind. gridAutoFlow: false was missing.

That sounds like a lot of work to disable CSS Grid 😕

If you replace all of the grid ones with just grid: false does that work?

If it doesn't already then I think the functionality should be added.

If you replace all of the grid ones with just grid: false does that work?

No, it does not. 😢

I think the functionality should be added.

👍

About grid-auto-rows need: I am building a calendar where I am using grid-cols. I'd like every cell to be the size of the biggest cell in the calendar. So that all cells are the same size.

Here's an example UI:

I was able to achieve it by adding a grid-auto-rows: 1fr1 on the main grid div. It would be nice to have a utility to do so! Thanks 🙏

Maybe there's another way to achieve that, dunno